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REMARKS 

Claims 1 and 3-41 are all the claims presently pending in the application. Claims 20, 
21, 22, 23, 24, 38, 39 are amended to more clearly define the invention. Claim 2 is canceled. 

These amendments are made only to more particularly point out the invention for the 
Examiner and not for narrowing the scope of the claims or for any reason related to a 
statutory requirement for patentability. 

Applicants also note that, notwithstanding any claim amendments herein or later 
during prosecution, Applicants' intent is to encompass equivalents of all claim elements. 

Claims 1 and 3-41 stand rejected under 35 U.S.C. § 103(b) as being unpatentable over 
Mitchell, et al. (U.S. Publication No. 2005/0229186) in view of Kaipa, et al. (U.S. 
Publication No. 2005/0114394). 

This rejection is respectfully traversed in the following discussion. 

I. THE CLAIMED INVENTION 

An exemplary embodiment of the claimed invention, as recited by, for example, 
independent claim 1, is directed to a method of discovering a business object definition that 
includes receiving an object and a collaboration code, and determining a business object 
definition for the object based upon the collaboration code . The collaboration code 
determines the business object definition for the object without pre-defined business object 
definitions, if the object does not conform to a known business object definition . 

Conventional systems and methods may include object discovery agents that produce 
business object definitions that include mapping information between object attributes and 
data fields in the application data sources. However, these methods and systems must 
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subscribe in advance to the pre-defined business object definitions , and can only exchange 
business objects of the business object definitions. Changes in business object definitions 
often render these conventional systems and methods useless . Further, these systems and 
methods often need to subscribe to a very large number of business object definitions. (See 
Application from page 2, linesl5-25 to page 3, lines 1-20). 

In contrast, the present invention is capable of dynamically determining a business 
object definition for an object based upon the collaboration code, without need to include pre- 
defined business object definitions . (See Application at page 6, lines 15-22). Thus, the 
present invention is capable of reverse engineering the composition of a business object to 
dynamically discover a business object definition, thereby obviating the above-described 
problems. 

II. THE PRIOR ART REJECTION 

The Examiner alleges that Mitchell, when combined with Kaipa, teaches or suggests 
all of the claimed features as recited by claims 1 and 3-41. Applicant submits, however, that 
these references would not have been combined and even if combined, the combination 
would not teach or suggest each and every element of the claimed invention. 

Claim 1 recites, inter alia: 

" receiving an object and a collaboration code; 

determining a business object definition for said object based upon said 
collaboration code; " 

storing said business object definition, 

wherein said collaboration code det ermine s said business object definition 
for said object without pre-defined business object definitions, if the object does 
not conform to a known business object definition. " 
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Support for the claimed features of claim 1 may be found in at least page 10, line 15- 
page 14, line 8 of the Specification. 

Claims 13, 20, 25, and 33 recite similar features as those recited by claim 1. 

The Examiner relies on paragraph 33 and 35 of Mitchell to attempt equating a 
procedure to manipulate data/ object as the claimed " collaboration code. " (Office Action, 
page 2, paragraph 4). However, paragraph 33 merely teaches that in order to aggregate new 
behavior and functionality to an interface or running object, the object must first be imported 
into the middleware network. To do this, it is necessary to gain access to the meta types for 
runtime objects. Also, paragraph 35 merely teaches that a illustrated implementation of the 
middleware framework described above supports automated importation of SOAP (Simple 
Object Access Protocol) interfaces. The XML meta data for other runtime types (for 
example, C++) may be handcrafted or generated with other methods. The interface 
recognizer that allows automated importation of SOAP interfaces (using a WSDL parser) 
may be modified to automate importation of COM, CORBA, RPC, Java, or any other type 
with runtime interfaces that are either discoverable or reverse engineerable. Entire libraries 
(in the context of adding types to a library, for example) may also be imported in this manner. 
Both paragraphs do not teach or suggest a procedure for manipulate data/object, and do not 
teach or suggest the claimed " collaboration code. " The Examiner also has not identified 
which part of the paragraphs 33 or 35 corresponds with the alleged procedure, or teaches or 
suggests " collaboration code. " Therefore, the Examiner has not met her burden to prove that 
Mitchell teaches or suggests, "receiving an object and a collaboration code; " 

The Examiner also relies on paragraph 34, lines 4-8 and paragraph 38, lines 3-5, and 
again attempts to equate an alleged procedure(s) to manipulate the data/object as the claimed 
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" collaboration code " to allege that Mitchell teaches or suggests, determining a business 
object definition for said object based upon said collaboration code; " However, as 
explained previously, Mitchell fails to teach or suggest, and the Examiner has failed to meet 
his burden to prove that Mitchell teaches or suggests, " collaboration code. " Also, paragraph 
34 of Mitchell merely teaches that the reason the imported object remains unaffected by the 
aggregation is that the middleware system automatically creates a Meta Data Definition 
Object (MDDO) from the discoverable type definitions of the imported object . Here, the 
Examiner appears to cite Mitchell's MDDO and discoverable type definition out-of-context, 
without understanding that Mitchell's MDDO definition is based on the imported object , 
rather than " collaboration code. " .Similarly, paragraph 38 merely teaches that when a type is 
recognized by the Interface Recognizer 107, the middleware automatically generates an 
MDDO (Meta Data Definition Object) . The MDDO may be a meta object instance of the 
class structure contained in the meta interfaces of the imported type. Here, the Examiner 
again mistaken MDDO as the claimed " business object definition. " and has not identified 
which structure of Mitchell teaches or suggests, " collaboration code " that the " business 
object de finition " is based on. Therefore, the Examiner has failed to meet her burden to 
prove that Mitchell teaches or suggests, determining a business object definition for said 
object based upon said collaboration code; " 

Kaipa also fails to remedy Mitchell's deficiencies. 

The Examiner has not even alleged, and Kaipa fails to teach or suggest, "receiving an 
ob ject and a co llaborati on co de" and " determini n g a business object definition jor said 
object based upon said collaboration code. " Instead, the Examiner merely alleges that Kaipa 
teaches or suggests, storing said business object deli a it ion, wherein said collaboration code 
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determines said business object definition for said object without pre-defined business object 
definition s, if the obj ect does not c onform to a known business object definition. " (Office 
Action, page 2, paragraph 4). However, Kaipa also does not teach or suggest '' wherein said 
collaboration code determines said business object definition for said object without pre- 
defined business object definitions, if the object does not conform to a known business object 
definition. " 

The Examiner relies on paragraph 39, lines 1-3 and 7-10 of Kaipa to allege that Kaipa 
teaches or suggests, " wherein said collaboration code determines said business object 
definition for said object without pre-defined business object definitions, if the object doe s 
not conform to a known business object d e finition. " (Office Action, page 3, lines 1 -5). 
However, paragraph 39, lines 1-3 merely teaches that once loaded, the automated object 
discovery agent (ODA)/conversion agent 311 proceeds to apply the mapping and naming 
criteria and generate a business object definition, without teaching or suggesting that Kaipa' s 
business object definition is determined " without pre-defined business object definitions, " 
under the condition " if the object does not conform to a known business object definition. " 
Also, paragraph 39, lines 7-10 merely teaches that the resultant business object definition (in 
this case, preferably a Java object) is forwarded to the connector 310 for use in runtime 
object. If another schema is ready to be operated on, the process is repeated. 

The Examiner alleges that "(Kaipa' s) definition stored in a business object is 
interpreted as unknown because the schema is XML and the business object definition 
created is java." (Office Action, page 3, lines 2-5). However, it is unclear what the Examiner 
meant. Here, it appears that the Examiner does not even have an understanding of what 
Kaipa teaches or suggests to one of ordinary skill in the art. Here, Kaipa does not teach or 
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suggest, and the Examiner has not identified any element of Kaipa that corresponds with the 
claimed " collaboration code " that " determines said business object definition for said object 
without pre-defined business object definitions , " under the condition, " if the object does not 
conform to a known business object definition. " While Kaipa teaches that the object 
discovery agent (ODA)/conversion engine 3 1 1 proceeds to apply the mapping an naming 
criteria, and generate a business object definition (step 440), Kaipa fails to teach or suggest 
that the generation is done " without pre-defined business object definitions , " under the 
condition "if the object does not con form to a known business object definition. " That is, 
Kaipa does not even make a determination, " if the object does not conform to a known 
business object dejvutign. " Whether Kaipa's business object definition is in an XML schema 
component or a JAVA component conversion has nothing to do with whether Kaipa's object 
" confo r m to a know n business ob j ect definition. " 

It also would not be obvious to combine Mitchell with Kaipa, even if Mitchell and 
Kaipa teaches or suggests all of the alleged respective features of claim 1. 

In re Kahn states that, "Rejection based on obviousness grounds cannot be sustained 
by mere conclusory statements; instead, there must be some articulated reasoning with some 
rational underpinning to support the legal conclusion of obviousness. In re Kahn, 441 F. 3d 

977, 988 The Supreme Court in KSR International Co. v. Teleflex Inc. , 550 U.S. , , 

82 USPQ2d 1385, 1395-97 (2007) identified a number of rationales to support a conclusion 
of obviousness which are consistent with the proper "functional approach" to the 
determination of obviousness as laid down in Graham. The key to supporting any rejection 
under 35 U.S.C. 103 is the clear articulation of the reason(s) why the claimed invention 
would have been obvious. The Supreme Court in KSR noted that the analysis supporting a 
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rejection under 35 U.S.C. 103 should be made explicit . 



Exemplary rationales that may support a conclusion of obviousness include: 

(A) Combining prior art elements according to known methods to yield predictable 
results; 

(B) Simple substitution of one known element for another to obtain predictable results; 

(C) Use of known technique to improve similar devices (methods, or products) in the same 
way; 

(D) Applying a known technique to a known device (method, or product) ready for 
improvement to yield predictable results; 

(E) "Obvious to try" - choosing from a finite number of identified, predictable solutions, 
with a reasonable expectation of success; 

(F) Known work in one field of endeavor may prompt variations of it for use in either the 
same field or a different one based on design incentives or other market forces if the 
variations are predictable to one of ordinary skill in the art; 

(G) Some teaching, suggestion, or motivation in the prior art that would have led one of 
ordinary skill to modify the prior art reference or to combine prior art reference teachings to 
arrive at the claimed invention. (See MPEP 2143). 

Here, the Examiner merely made a conclusorv rationale that it would have been 
obvious, at the time the invention was made, to have modified the teaching of Mitchell by the 
teaching of Kaipa to provide a better way to carry out the conversion of XML schema to Java 
and other object definitions. (Office Action, page 3, lines 7-10). However, Mitchell is not 
even concerned with converting XML schema to Java. Rather, Mitchell is concerned with 
dynamically aggregating data and functionality runtime objects in order to increase 
component reuse and ease integration of disparate objects. (See Abstract), which is unrelated 
to Kaipa' s method for mapping and labeling XML schema elements and types (to Qualified 
Java components) (See Abstract and title). In fact, Mitchell does not even recognize that 
there is a problem with converting XML schema to Java. Similarly, Kaipa also does not 
improve upon Mitchell's attempt to dynamically aggregate data and functionality to runtime 
object in order to increase component reuse and case integration of disparate objects. 
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Since Mitchell and Kaipa are unrelated , one of ordinary skill in the art would not have 
even considered combining the two references to teach or suggest all of the features of the 
claimed invention. 

Regarding claims 3-12, 14-24, 26-32, and 34-43, the Examiner did not even provide a 
rationale to combine Mitchell with Kaipa to teach or suggest the dependant claims. 
Therefore, the Examiner has not satisfied her burden to prove that it would have been obvious 
to one of ordinary skill in the art at the time the invention was made to have considered 
combining Mitchell and Kaipa to teach or suggest the claimed inventions of the above claims. 

Further, the Examiner has not alleged, and both Mitchell and Kaipa fail to teach or 
suggest, the amended features of claims 20-23, and 38. 

The Examiner also alleges that Mitchell teaches or suggests claim 39 's features 
' " wherein the processor for receiving the object and the collaboration code, and for 
determining the object definition for said object based on said collaboration code, and the 
collaboration code for determining whether the object conforms to the known business object 
definition, comprise a reverse object discovery agent means, " (Office Action, page 7, lines 
23-28) by relying on paragraph 22 of Mitchell. However, Mitchell merely teaches that 
Aggregation in embodiments of the present invention may depend on: the existence of an 
object with meta data that may be discovered or reverse-engineered, (Paragraph 22) which 
does not necessarily mean that there is indeed a processor that includes all of the functions as 
claimed, and includes all of the structural features included in the specification that describes 
" a reverse object discovery agent means ." Kaipa also does not remedy Mitchell's 
deficiencies because the Examiner does not even allege, and Kaipa fails to teach or suggest, 
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the above-recited features of claim 39. Therefore, the Examiner failed to satisfy her burden 
to prove that Mitchell and Kaipa teaches or suggests all of the features of claim 39. 

With regard to claim 41, since Mitchell and Kaipa do not teach or suggest all of the 
features of claim 1, the references also do not teach or suggest the sequence of the steps of 
claim 41. 

Since there are features of the claims that are neither taught nor suggested by the 
above-cited reference, reconsideration and withdrawal of the rejections is respectfully 
requested. 

III. FORMAL MATTERS AND CONCLUSION 

In view of the foregoing amendments and remarks, Applicants respectfully submit 
that claims 1 and 3-41, all the claims presently pending in the Application, are patentably 
distinct over the prior art of record and are in condition for allowance. The Examiner is 
respectfully requested to pass the above application to issue at the earliest possible time. 

Should the Examiner find the Application to be other than in condition for allowance, 
the Examiner is requested to contact the undersigned at the local telephone number listed 
below to discuss any other changes deemed necessary in a telephonic or personal interview. 
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The Commissioner is hereby authorized to charge any deficiency in fees or to credit 
any overpayment in fees to Assignee's Deposit Account No. 50-0510. 

Respectfully .Submitted, 



Date: July 9, 2010 




Jeoyuh Lin, Esq. 
Registration No. 56,032 



Sean M. McGinn, Esq. 
Registration No. 34,386 

McGinn Intellectual Property Law Group, PLLC 

8321 Old Courthouse Rd„ Suite 200 
Vienna, Virginia 22182 
(703) 761-4100 
Customer No. 48150 



